Busting Myths in Foxit Reader

UPDATE: Since publishing this blog, a Foxit representative reached out to us with the following statement:
"Foxit Software is deeply committed to delivering secure PDF products to its customers. Our track record is strong in responding quickly in fixing vulnerabilities. We are currently working to rapidly address the two vulnerabilities reported on the Zero Day Initiative blog and will quickly deliver software improvements. In the meantime, users can help protect themselves by using the Safe Reading Mode. We apologize for our initial miscommunication when contacted about these vulnerabilities and are making changes to our procedures to mitigate the probability of it occurring again."
We are pleased to know they reversed course on these bugs. We thank the folks at Foxit for reconsidering this matter. The Foxit team have been good partners in the past, and we look forward to working with them again in future.

We recently (15 minutes ago) published two 0-day advisories for vulnerabilities in Foxit. You can read the advisories here and here. These vulnerabilities were found by Steven Seeley (mr_me) and Ariele Caltabiano (kimiya). The beauty of these vulnerabilities is their simplicity by nature, and that they are not memory corruption vulnerabilities. To be exact, they are Command Injection and File Write vulnerabilities that can be triggered through the JavaScript API in Foxit Reader.

In order to trigger these vulnerabilities, an attacker would need to bypass Safe Reading Mode. Sadly, the vendor decided not to fix the vulnerabilities due to this fact and provided the following statement:

“Foxit Reader & PhantomPDF has a Safe Reading Mode which is enabled by default to control the running of JavaScript, which can effectively guard against potential vulnerabilities from unauthorized JavaScript actions.”

We disagree that this mitigation is sufficient protection from these bugs. This blog describes the vulnerabilities and how they can be used to execute code.

The vulnerabilities:

ZDI-CAN-4724 (CVE-2017-10951) – Foxit Reader app.launchURL command Injection:

This vulnerability was found and submitted to us by Ariele Caltabiano (kimiya). The vulnerability exists within app.launchURL. I must admit that this vulnerability made me smile when I first saw it, especially since it looked similar to a vulnerability that I found in Adobe Reader in 2015 and patched last year: ZDI-16-285.

We’ve always assumed (or at least I did) that app.launchURL strictly takes URLs as arguments. In Foxit, this is not an accurate assumption at all because:

1. It does not check whether or not the argument is an actual URL. In fact, it accepts full paths.
2. It does not filter any file extensions and hence we can simply execute commands.

It not only fails to check the above, but it also passes the full path to a ShellExecuteW with the lpOperation argument set to open:

We can verify this further in WinDBG by executing:

        app.launchURL(“c:\\windows\\system32\\write.exe”):

And here’s a video that demonstrates the vulnerability:

ZDI-CAN-4518 (CVE-2017-10952) – Foxit Reader saveAs Arbitrary File Write

This vulnerability was found and submitted to us by Steven Seeley (mr_me). The vulnerability exists within the this.saveAs JavaScript function. This is one of the few bugs that actually made me facepalm, hard.

The myth says that this API is supposed to be used to save the document (PDF file format) to certain paths. Well, Foxit Reader busted this myth. Here’s why:

1. saveAs does not properly check the path it is given to write to.
2. It does not check the file extension and hence we can simply write whatever we want.

Eventually, saveAs ends up calling WriteFile to write the file:

Steven exploited this vulnerability by embedding an HTA file in the document, then calling saveAS to write it to the startup folder, thus executing arbitrary vbscript code on startup.

The following trigger would write the file to the start up folder:

We can verify this in WinDBG:

Here’s a video that demonstrates the vulnerability:

Conclusion

 It’s quite amazing how much we can find by digging behind the scenes into Foxit’s JavaScript API. Users of Foxit’s Reader and PhantomPDF should ensure they have Safe Reading Mode and hope attackers don’t discover a way to disable it. Additionally, you can uncheck the “Enable JavaScript Actions” from Foxit’s Preferences menu, although this may break some functionality. 

A big shout out to our researchers who keep busting myths.

As always, I can be found on twitter @abdhariri, and follow the team for the latest in exploit techniques and security patches.